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ABSTRACT 


This  track  presentation  presents 
an  improved  Vehicle  Network 
(Data  Bus)  Protocol 
Selection  Process/Technique  for 
Ground-based  Military  Vehicle  Systems. 
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ABSTRACT  (cont) 


Vehicle  network  data  bus  protocols 
are  analyzed/evaluated  and  selected 
to  support  the  real-time  control  and 
information  data  gathering  requirements 
for  the  Brigade  Combat  Team  Platforms. 
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BACKGROUND 
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VEHICLE 


"ONE  TEAM  VISION  - 
EQUIPPING  OUR  JOINT  WARFIGHTERS 
WITH  THE  WORLD'S  BEST  CAPABILITY" 


The  selected  Vehicle  Network  (data  bus)  protocol(s)  can  be  installed  into  U.S. 
Army  Ground-based  Military  and/or  Commercial  (COTS)  Vehicle  Systems 
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DoD  Mission  Goals  /  Army  Vision 


..  The  technology  that  is  at  the 
center  of  Transformation  is 
Information  Technology” 

“...  a  network  centric  capable 
force  that  is  robustly  networked 
...  fully  interoperable  and  shares 
information  and  collaborates  by 

means  of  communications  and 
information  infrastructure  that  is 
global ,  secure ,  real  time,  reliable, 
internet  based,  and  user  driven  ” 

Arrival  Ceremony  for 
the  Secretary  of  the 
Army 


“We  will  become  more  sustainable. 
We  look  to  reduce  support  demands 
by  seeking  common-platform  / 
common-chassis  /  standard-caliber 
designs.” 


“The  lesson  of  this  war  is  that 
effectiveness  in  combat  will 
depend  heavily  on  jointness  - 
that  is ,  the  ability  of  different 
branches  of  our  Military  to 
communicate  and  coordinate 

efforts  across  the  battlefield.”... 

Former  Secretary  of 
Defense 

Donald  Rumsfeld 


...the  Army  still  has  a  lot  to 
learn  on  how  to  successfully 
build  such  an  advanced 
information  network. 

(FCS/BCT)  Former 
Program  Manager 
MG  Charles  Cartwright 

The  Army  Vision,  by  Gen.  Eric  K. 

Shinseki,  Former  Chief  of  Staff,  USA 
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US  Army  Philosophy 


•US  Army  Transformation  is  required  to  meet  the  challenges  of 
changing  conditions  across  the  spectrum  of  military  operations 
and  the  evolution  of  military  technologies 

•US  Army  Transformation  combines  advanced  technologies, 
organizations,  people,  and  processes  with  concepts  to  create 
new  sources  of  military  power  that  are  more  responsive, 
deployable,  agile,  versatile,  lethal,  survivable,  and  sustainable 

-  using  a  system-of-systems  (SoS),  not  a  collection  of  platforms 

-  is  network-centric,  not  platform-centric 
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RealTimeCommonOperatingEnvironment  (rtcoe) 


Application  Software 
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Key  Piece 


Vehicle  Network  Data  Bus(es)  w/Prorocol(s) 
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VEHICLE 


INTRODUCTION 
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PROBLEM 


There  are  many  parts  of  this  network  to  research; 

however,  I  shall  concentrate  on  defining 
a  precise  method  to  define  and  assist  in  properly 
selecting  the  network  (data  bus)  protocol  pieces, 
especially  within  a  BCT  Platform  (vehicle). 
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Data  Bus  /  Protocol 


In  vehicle  network  architectures,  a  data  bus  is  a  subsystem  that  transfers  data 
between  computing  devices/peripherals.  Unlike  a  point-to-point  connection,  a 
data  bus  can  logically  connect  several  peripherals/devices  over  the  same  set  of 
wires.  Each  data  bus  defines  its  set  of  connectors  to  physically  plug  devices, 
peripherals  or  cables  together. 

The  data  bus’  protocol  is  a  set  of  rules  governing  the  format  of  messages  that 
are  exchanged  between  the  computing  devices/peripherals.  Some  data  bus 
protocol  designers  employ  excessive  redundancy  and  parallel  data  paths  as 
solutions  for  latency,  large  %  utilization  rates,  throughput  and  survivability  issues; 
still  others  are  using  proprietary  protocols. 
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The  WRONG  Data  Bus/Protocol  Goal 


IIAIUOI  IXCILIII 


•Vehicle  manufacturers  prefer  their  vehicle 
architecture  employ  their  own  developed  data  bus 
and  protocol. 

•Case  in  Point  -  One  Government  contractor 
desired  that  ONE  Data  Bus  type  exist  in  the 
Vehicle’s  Electronic  Architecture! 

-They  preferred  GbE  only. 

-Dictated  and  not  arrived  at  scientifically. 
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Correct  Data  Bus/Protocol  Goals 


•Technical  -  Size,  Weight  and  Power 
(SWaP) 

•Cost  -  Lowest/Reasonable 

•Schedule  -  Available/On  Track 

•Performance  -  Highest  Technology  Risk 
Level  /  Risk  Free 
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Key  Data  Bus/Protocol  Conundrum 


IIAIUOI  IXCILIII 


General  area  is  one  where  many  people  have 
less  understanding  than  they  think  they  do. 

Mike  Green  -  NPS 
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NO  Data  Bus  /  Protocol  Usage  Here 
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Program  Manager’s  Vehicle  Network  Goal 


VEHICLE 


To  move  infinite  amounts  of  data 


In  no  time 


In  thin  air! 
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Vehicle  Network  (Data  Bus)  Protocol 
Reality 


Propulsion  Cooling  System 

Low  Voltage  Power  Distribution 

Environmental  Control  System 

Nuclear  Biological  Chemical  Filtration 
System 

Advanced  Man-Machine  Interfaces 

Embedded  Predictive 
Logistics  Sensors  &  Algorithms 


High  Power  Density 
Engine 

Fuel  Efficient  Hybrid 
Electric  Propulsion 


Signature 

Management 

Power  Distribution 
And  Control 

High  Density 
Packaged  Power 


Air  Handling  Unit 

In-Arm  Hydro  Pneumatic 
Suspension 


Vehicle  Network(s) 

SW  Programmable  Radio  Suite  &  Antennas 
Real-time  Vehicle  Control  Data  Buses 
Information  Exchange  (Enterprise)  Systems  Data  Buses 
Decision  Aids 

Distributive  Collaboration  of  Manned/Unmanned  Platforms 
Security  Intrusion  Detection 
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VEHICLE  NETWORK 
(DATA  BUS)  PROTOCOL 

SELECTION 

PROCESS/TECHNIQUE 
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Previous  Network  Selection  Iterations 


Vehicle  Network  Selection  Conducted  2002 

-CAN  Data  Bus  recommended 

-Simple  Mathematical  selection  method  used 

Vehicle  Network  Selection  Conducted  2003-2005 

-CAN  Data  Bus  recommended  for  lower  speed  hard  real  time  control 

-  IEEE  1394b  Data  Bus  recommended  for  high  speed  hard  real  time  control 

-  Formal  Trade  Study  Process  w/  software  assisted  method  used 

-  Process  conducted  twice  during  contract  period  of  performance 
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SOLUTION  DEVELOPMENT  METHODOLOGY  1 


My  NPS  Software  Engineering  PhD  Dissertation  Research  is  centered  on 
presenting  an  improved  (new)  Vehicle  Network  (Data  Bus)  Protocol  Selection 
Process/Technique  for  Ground-based  Military  Vehicle  Systems. 

Worldwide  standard  (ISO/SAE)  and  emerging  (industry/academia)  Vehicle 
network  (data  bus)  protocols  are  to  be  analyzed/evaluated  and  categorized  by 
an  all-encompassing,  feature-based  technique  to  define  the  (non)real-time 
control  and  information  data  gathering  requirements  for  the  BCT  Platforms. 

By  feature-orientation,  my  goal  is  to  make  the  mapping  relationship  between 
vehicle  network  (data  bus)  protocol  requirements  and  the  Vehicle  Network 
Selection  Process/Technique  selected  architecture  straightforward  and 
defendable. 
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SOLUTION  DEVELOPMENT  METHODOLOGY  2 


A  Feature  can  be  defined  as:  A  feature  is  “a  coherent  and  identifiable  bundle  of 
system  functionality  that  helps  characterize  the  system  from  the  user  perspective”; 
A  feature  is  “a  prominent  or  distinctive  user-visible  aspect,  quality,  or  characteristic 
of  a  software  system  or  systems”;  A  feature  is  “an  externally  desired  service  by  the 
system  that  may  require  a  sequence  of  inputs  to  effect  the  desired  result”;  A 
feature  is  “a  service  that  the  system  provides  to  fulfill  one  or  more  stakeholder 
needs”. 

Dongyun  Liu  and  Hong  Mei  of  the  Institute  of  Software,  School  of  Electronics 
Engineering  and  Computer  Science  ,  Peking  University,  Beijing,  China  find  that  “a 
feature  is  a  higher-level  abstraction  of  a  set  of  relevant  detailed 
software(/hardware/firmware)  requirements,  and  is  perceivable  by  users  (or 
customers(/system  developers))”.  These  features  (requirements)  must 
somehow  be  categorized  or  processed  (traded-off)  to  form  a  hierarchal  feature 
(requirement)  selection  characterization  method  to  classify/tradeoff  requirements 
for  my  “best  pick(s)”  method  for  the  “just  right”  vehicle  network  (data  bus)  protocol. 
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SOLUTION  DEVELOPMENT  METHODOLOGY  3 


•The  quantity  and  quality  of  network  design  features  analyzed  by 
previous  network  selection  techniques/tools  were  insufficient  to  pick 
correct,  mutually  accepted  vehicle  network  (data  bus)  protocols  for  the 
DoD’s  BCT  Platform  or  its  legacy  programs  that  preceded  it. 

•Use  previous  selection  methods  as  one  of  the  best  previous  competing 
solutions  to  act  as  a  starting  point  for  the  framework  of  my  new  feature- 
based  vehicle  network  selection  process/technique. 

•  Use  all  of  the  founding  principles  and  merits  of  a  BCT  Common 
Operating  Environment  to  act  as  the  “most  favored”  features  of  the 
selection  software  and  employ  a  fuzzy  logic  rules-based  and/or 
simulation  toolset  that  shall  evolve  into  the  best  vehicle  network  protocol 
selection  tool  to  date. 

•  The  new  vehicle  network  protocol  selection  process/technique  shall 
employ  over  double  the  number  of  measures  of  network  features  to 
assess  all  candidate  vehicle  network  protocols  against  previous 
selection  methods. 
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SOLUTION  DEVELOPMENT  METHODOLOGY  4 


First,  conduct  a  survey  of  the  network  requirements  of  typical 
vehicle  networks.  These  “features”  shall  then  be  used  to  help 
define  the  best  feature-based  architecture  for  the  BCT  Platforms. 

Second,  rather  than  use  a  handful  or  limited  set  of  parameters  to 
define  a  vehicle  network  (data  bus)  protocol  for  the  purposes  of 
supplying  the  inputs  to  a  trade  study,  it  is  better  to  define  the  key 
features/requirements  that  represent  all  present  day  vehicle 
network  (data  bus)  protocols  and  use  them  in  an  unified  (automatic) 
trade-off  analysis  selection  process  to  select  the  data  bus 
protocol(s)  needed  by  the  developer  to  be  used  across  all  product 
line  products,  or  in  this  case,  vehicles. 

Third,  place  these  features  into  a  personally  developed  vehicle 
network  protocol  selection  tool,  add  a  developer’s  specific 
requirements  and  observe  the  results.  Repeat  using  another 
developer’s  requirement  inputs  as  necessary  to  refine  the  tool  for 
effective  use  in  the  ground-based  military/COTS  vehicle  domain. 
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Vehicle  Network  Protocol  Selection  - 
My  Iteration  1 

New  Key  Feature-based  Selection  Criteria: 

•Based  on  key  features  of  a  vehicle  network  (data  bus) 

•Based  on  vehicle  network  (data  bus)  protocol  feature 
(requirement)  characterization/tradeoffs 

•Based  on  actual  functionality  of  the  vehicle  network  (data  bus) 
•Based  on  common  sense  and  actual  industry  practice(s) 
•Based  on  inherent  Pit  Stop  Design/Engineering  principles 
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Vehicle  Network  Protocol  Selection  - 
My  Iteration  2 

Research  Requirements  Characterization  and  Tradeoff  Methods: 

-Analyze  Requirements  Tradeoffs 

•Systematic  Tradeoff  Analysis  for  Conflicting  Imprecise  Requirements 
•Architecture  Tradeoff  Analysis  Method  (ATAM) 

-Analyzing  the  Tradeoffs  among  Requirements,  Architectures  and  COTS- 
Based  Systems 

-Tradeoffs  in  Weapon  System  Design 
-Quantitative  Methods  for  Tradeoff  Analyses 

•Figure  of  Merit 
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Pit  Stop  Engineering  Applied  to  Vehicle 
Network  Protocol  Selection  Process/Technique 


•  Simplified  Architecture 

-  Follow  Army  Enterprise  Architecture  (JTA-Army)  Guidance 

•  High  Use  of  existing  Standards  or 

Promote  Development  of  New  SAE/IEEE/ISO  Standards 

•  Standard  Naming  Convention  for  RTCOE  &  Vetronics  features 

•  Extensive  use  of  Vehicle  Network(s)/Data-Bus(es)  for  System  Data  Flow 

•  Generic  Features/Attributes  for  High  Reuse 

•  Achieve  Lowest  Cost/Highest  Supportability/Maintainability/Reliability 
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A  Just  Right  Vehicle  Network  Protocol?  £ 


VEHICLE 
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List  of  Acronyms 
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•ATAM  -  Architecture  Tradeoff  Analysis  Method 

•BCT  -  Brigade  Combat  Team 

•CAN  -  Controller  Area  Network 

•COTS  -  Commercial  Off-the-Shelf 

•DoD  -  Department  of  Defense 

•GbE  -  Giga-bit  Ethernet 

•IEEE  -  Institute  of  Electrical  &  Electronic  Engineers 
•ISO  -  International  Standardization  Organization 
•JTA-Army  -  Joint  Technical  Architecture  -  Army 
•RTCOE  -  Real-Time  Common  Operating  Environment 
•SAE  -  Society  of  Automotive  Engineers 
•SoS  -  System-of -Systems 
•SWaP  -  Size,  Weight  and  Power 
•Vetronics  -  Vehicle  Electronics 
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